dreamemulatorfandomcom-20200223-history
Data Analysis
Location ID numbers These can be derived either from the textures (TIX files on cd) or from the memory by inspecting the current_location variables. File Structure In the root of the disc is a folder called CDI in which all the game data is stored. A folder called CARD contains the bulk of the user interface assets in TIM format, ETC contains the non-dream videos and fonts, FILM contains the dream videos and any "EVENT" videos triggered by interacting with the world such as the ferris wheel or the gear room. IMG1 and IMG2 contain the pages of Kanji sometimes seen instead of a dream. SND presumably refers to sound. Finally, a list of folders called STGxx, where xx is the Location ID. STGxx STG is likely a shortening of STAGE, as each STG appears to contain data for a specific room or area. TIX Files There are four .TIX files in each stage, TEXy.TIX, where y is ranging from A to D. The first contains the "normal" textures, while the second contains the "Kanji" textures, the third contains "downer" textures and the fourth contains "upper" textures. SEQ Files Each STGxx folder has five BGz.SEQ files, where z is ranging from A to E (BGA.SEQ to BGE.SEQ). This is only speculation but the small size of these files relative to others and the extension (SEQ=SEQUENCE) leads this dreamer to deduce that these might be script or entity list files. That there are always five is interesting; it may be that there is a "root" script file that contains entities seen through all four texture packs, while the four that follow add or remove objects depending upon the specific texture pack. These files always begin with a "magic number" of "pQES" followed by "1" as a big-endian value. While the PS1 was little-endian as far as this dreamer knows, the dream journal mentions using a Macintosh, which was big endian, and the tools used to create these scripts were likely on a Mac as a result. 1 could refer to a version number. Note that pQES is SEQp which backs this up. Beyond the magic number, the data is as of yet indecipherable. It usually follows some degree of structure but the meaning is not clear. LBD Files These files sit between the SEQ and TIX files in terms of size and as such this dreamer thinks they may be tile maps for the world - LBD may refer to Level Build Data or such. It may be noted that the entire game could be built using a 2D grid - all of the structures are square or placed on the grid, and even in rooms with vertically overlapping sections such as the starting house/hotel, the levels are accessed by automatically guided staircases which could seamlessly swap out the layers. As far as the file sizes go, it is unclear why they vary so much. It is possible that they are compressed. When loading them as RAW bitmaps into Paint Shop Pro, it looks like there's some sparse header then a dense data section with some kind of pattern but the precise row pitch needed to see it as intended is not clear. Perhaps this is in the header. In larger environments these files are split into subfolders called Nx, which in the Natural World, for instance, span all the way from 1-9. The reasoning behind this is unclear but perhaps it was just to keep the folder structure tidier. Maybe there were filesystem limitations or the map was split between developers. Breaking It Down By examining the TIX files, we can observe that STG10 is the long corridor. This is the simplest map I can think of so let's have look in the .LBD files, beginning with 000. The file opens, as little endian 32-bit integers, as: 1 <-Version? Maybe depth as it's 1 high? 24 <-Width? 4808 <-Height? 8160 <-Possibly some kind of offset 14336 <-If the above is X this is Y 0 <-Entities? Chance of being picked when linking? 76 <-? 20 <-? If you take this to be the header, 32 bytes, and view it as a raw RGB bitmap with a width of 24 you get: Not only does that make something vaguely coherent, but there's two lines! Could this be the corridor? Let's try it with another map. Comparing With Another Map Let's try M000.LBD of STG05 (Location ID=5 ⇒ Violence District). Here's the header: 1 24 <- Hmm definitely not width then 4808 <- Definitely not height 15272 <- This is different 20480 <- Also different 0 <- Same 76 <- Same 20 <- Same Interesting that so much would be different. Perhaps those two straight lines were merely coincidence? Let us try loading this map with a width of 24. Hmm... that headery section is similar. Further investigation required but that COULD be the motorway. However, I'm not convinced. Note that it's roughly 200 lines before the noisy bit below. 24 (width) x 200 (height) = 4800 which is very close to the 4808 in the header. Let's see what the rest of the file looks like. 76x20 is 1520 bytes which doesn't come close to filling the rest of the file. I'm sure the map isn't 15272x20480 because even at one byte per tile that's nearly 300mb. The file, however, is 20480 bytes long, so perhaps 15272 is an offset into the file. Nothing particularly enlightening happens at that offset though the content changes a little. Looking back at the corridor LBD, it states 14336 where the VD states its own length and given that the file is only 12992 bytes long it's unlikely to be the file size OR an offset. Let's Try Another Map It's quite possible that two identically sized maps were picked there so let's grab another one. M001 from STG05. Header: 1 <- Same again 24 <- Same again 4808 <- Same again 21352 <- Within the bounds of the file which is exactly 32kb (32768 bytes) 26624 <- As above 6144 <- First time it's been non-zero 76 <- Same again 20 <- Same again I could put the image here but it's very similar - two stripes. I wonder if the data is compressed... it compresses well under 7zip (5:1) so I'd say not. Memory analysis One way to understand the underlying game mechanics is to perform memory analysis on an emulator running the game. Once the analyst know about a variable, the variable itself can be monitored for studies. A variable can be modified directly by changing the memory of the emulator process. The game behaviour can also be modified if the instructions are changed. How to analyse the memory Cheat engine is a program made for game memory modification. LSD: Dream Emulator running on the emulator pSXfin v1.13 was tested and worked well together with Cheat engine. There is rar file containing a version of Cheat engine without (the potentially unwanted) OpenCandy on their official website download page. Be sure to read the guides available for free on various websites and to try Cheat engine with their demo tool before analysing the game. Be sure to specify the memory region to scan from the adress psxfin.exe+171A5C (2 MB game memory) and 0x200000 steps ahead instead of the entire emulator process memory (around 30 MB). Step-by-step guide Before starting Cheat engine, start the emulator application, load the CD image and start a new dream. Once you have run the Cheat engine main application, open the Process List window and select the emulator process. Locating a days variable In this example, we will modify the number of days that has passed in the game. This game screen show us that we are on day 110. The game stores this as current_day = 109 with two different 4 Byte variables. Enter 110 - 1 = 109 as Value and press First Scan. Some variables that contains the value 109 will appear in the window to the left. Some of these are unrelated but simply happen to contain the value 109. Play through a dream and the day will change - along with the dependant variables. Now enter the next current day Value 111 - 1 = 110 in Cheat engine and press Next Scan. This will filter out all variables that are not equal to 110. This is a good thing as they are unrelated. A finished scan should have two variables that are dependent as we already knew that there were exactly two variables that contains days - 1. These can now be monitored or modified. Try entering Flashback mode. The variables will change indicating which day the Flashback is from. Once your Flashback dream is over, try changing both variables to a high value (more than 365). This has been speculated to trigger more frequent The Gray Man visits. Memory structure There are some variables that control textures and some that are affected by The Gray Man if you get too close to him but those are complicated to map. Huge parts of the memory are modified when bouncing into something, linking and with The Gray Man encounters. Known variables The offsets are measured from the beginning of the game memory. The variables are reached by adding the value found at psxfin.exe+171A5C. In Cheat engine, this is done by referring to psxfin.exe+171A5C as a pointer with the specified offset. Day There are two 4-byte integers that both contain day-1. These can be modified. Timer You can get and set the amount of time you have spent on a location with this variable. It is stored close to the current_day variable, suggesting that they are used for seeding randomness or that they are key variables. Some memory locations nearby fluctuates a lot. This might suggest that the location is used for randomness. Modifying this does not influence gameplay directly. Location Each location has a unique ID which is the same one as files are indexed (including texture files). Maybe setting the values to 4 (Happy Town) would trigger more The Gray Man visits and setting them to 0 (Bright Moon Cottage) would disable them. They are numbered by the order they change when linking. They keep the same value once linking is done. The value equals one of the location ID numbers. Invariant: 0 ≤ current_location ≤ 13. Changing them during a half-complete linking will corrupt maps and sometimes freeze the game. Events There is also an event counter. This increases by one when linking and seems to increase when the player triggers events. This can be used to detect if something happens. Future memory analysis Textures The texture filenames are stored as text strings. There seems to be pointers to them. They might explain how textures are swapped. Another possibility is that the text strings are only stored by the emulator software. Chart Mechanics The graph changes when the user first modifies the days variables and then enters the graph screen, suggesting that the positions are stored in arrays. Some unknown variables could also be correlated with the x and y positions on the graph screen you see after each dream. The linking screen colors might be correlated to the positions. One problem is that it is unknown how, not just where, those potential variables are stored. They could also be based on calculations with lots of data. It is also hard to know where zero is on the graph and how that should be interpreted. Category:Gameplay Elements